Scheduling of Software Package Transmissions on a Multimedia Broadcast Multicast Service Channel

ABSTRACT

A computing device may schedule transmission of software packages on a broadcast/multicast downlink channel. The schedule may also include media transmissions on the channel, and the software package transmissions may be scheduled for times when the media transmissions are using less than or equal to a threshold capacity level of the channel. A software update request may be received from a wireless computing device. Possibly in response to receiving the software update request, a particular software package related to the wireless computing device may be determined. The particular software package may be scheduled to begin transmission on the channel at a particular time. At least an identifier of the channel and the particular time may be transmitted to the wireless computing device.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a continuation application of U.S. patentapplication Ser. No. 14/594,562, filed on Jan. 12, 2015, entitled“Scheduling of Software Package Transmissions on a Multimedia BroadcastMulticast Service Channel”, the contents of which are entirelyincorporated by reference herein for all purposes.

BACKGROUND

Multimedia broadcast multicast service (MBMS) channels may be used innetworks to distribute content to wireless computing devices (WCDs).This content may include multimedia, such as streaming audio and/orvideo. By transmitting the content on an MBMS channel, one transmissioncan potentially be received by a large number of WCDs. As a result, lessnetwork capacity may be used in comparison to unicasting thetransmission to each of the WCDs separately.

SUMMARY

Since MBMS channels support packet-switched communication, thesechannels can be used for transporting any sort of digital content from asource device to one or more destination devices. Consequently, in somecases, it may be advantageous to distribute software updates, and/orrelated types of files, to wireless computing devices using MBMS.Particularly, a specific software package (e.g., a software update) fora specific operating system and/or device type may be scheduled fortransmission on an MBMS channel when that channel would otherwise beidle. Alternatively or additionally, the software package transmissionmay be scheduled for when some, but not all, of the capacity of the MBMSchannel is in use. These software packages may include new versions of awireless computing device operating system, library, application, and/ora data file.

Accordingly, in a first example embodiment, a computing device mayschedule transmission of software packages on a broadcast/multicastdownlink channel. The schedule may also include media transmissions onthe broadcast/multicast downlink channel, and the software packagetransmissions may be scheduled for times when the media transmissionsare using less than or equal to a threshold capacity level of thebroadcast/multicast downlink channel. A software update request may bereceived from a wireless computing device. In some embodiments thiscould be a device information exchange message. Possibly in response toreceiving the software update request, a particular software packagerelated to the wireless computing device may be determined. Theparticular software package may be scheduled to begin transmission onthe broadcast/multicast downlink channel at a particular time. At leastan identifier of the broadcast/multicast downlink channel and theparticular time may be transmitted to the wireless computing device.

In a second example embodiment, an article of manufacture may include anon-transitory computer-readable medium, having stored thereon programinstructions that, upon execution by a computing device, cause thecomputing device to perform operations in accordance with the firstexample embodiment.

In a third example embodiment, a computing device may include at leastone processor, data storage, and program instructions. The programinstructions may be stored in the data storage, and upon execution bythe at least one processor may cause the computing device to performoperations in accordance with the first example embodiment.

In a fourth example embodiment, a system may include means forscheduling transmission of software packages on a broadcast/multicastdownlink channel, where the schedule also includes media transmissionson the broadcast/multicast downlink channel, and where the softwarepackage transmissions are scheduled for times when the mediatransmissions are using less than or equal to a threshold capacity levelof the broadcast/multicast downlink channel. The system may also includemeans for receiving a software update request from a wireless computingdevice. The software update request may take the form of a deviceinformation exchange message, and this message can also include theindication that the wireless computing device supports MBMS forover-the-air (OTA) updates, and may indicate what version of software iscurrently installed on the device. The system may further include meansfor, in response to receiving the software update request, determining aparticular software package related to the wireless computing device,where the particular software package is scheduled to begin transmissionon the broadcast/multicast downlink channel at a particular time. Thesystem may additionally include means for transmitting, to the wirelesscomputing device, at least an identifier of the broadcast/multicastdownlink channel, and the particular time.

These as well as other embodiments, aspects, advantages, andalternatives will become apparent to those of ordinary skill in the artby reading the following detailed description, with reference whereappropriate to the accompanying drawings. Further, it should beunderstood that this summary and other descriptions and figures providedherein are intended to illustrate embodiments by way of example onlyand, as such, that numerous variations are possible. For instance,structural elements and process steps can be rearranged, combined,distributed, eliminated, or otherwise changed, while remaining withinthe scope of the embodiments as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an MBMS networked environment, according to exampleembodiments.

FIG. 2 illustrates a schematic drawing of a wireless computing device,according to example embodiments.

FIG. 3 illustrates a schematic drawing of a content server device,according to example embodiments.

FIG. 4 is a depiction of transmission schedules, according to exampleembodiments.

FIG. 5A is a message flow diagram, according to example embodiments.

FIG. 5B is another message flow diagram, according to exampleembodiments.

FIG. 6 is a flow chart, according to example embodiments.

DETAILED DESCRIPTION

Example methods, devices, and systems are described herein. Herein, thewords “example” and “exemplary” are used herein to mean “serving as anexample, instance, or illustration.” Any embodiment or feature describedherein as being an “example” or “exemplary” is not necessarily to beconstrued as preferred or advantageous over other embodiments orfeatures. Other embodiments can be utilized, and other changes can bemade, without departing from the scope of the subject matter presentedherein.

Thus, the described example embodiments are not intended to be limiting.Aspects of the present disclosure, as generally described herein andillustrated in the figures, can be arranged, substituted, combined,separated, and designed in a wide variety of different configurations,all of which are explicitly contemplated herein.

1. Overview

Multimedia broadcast multicast service (MBMS) is a point-to-multipointpacket-data service in which content is transmitted from a single sourceto one or more destinations. While MBMS channels can be deployed incellular networks, using cellular wireless spectrum, other types ofwireless networks can potentially support MBMS as well. As used herein,the term “MBMS” shall encompass any type of MBMS deployment, such asMBMS over Long Term Evolution (LTE®) networks, which is sometimes called“eMBMS.” MBMS is used in this description as one embodiment, but otherbroadcast services can be used as well.

MBMS can support at least two delivery modes, streaming media and filedownloads. As an example, the streaming media service may be used fortransmission of live audio or audio/video from sporting events and musicconcerts. Additionally, the streaming service can support non-real-timetransmission of audio or audio/video, such as on-demand television,streaming music, podcasts, and so on. On the other hand, the downloadservice may support delivery of news, weather, and other types ofinformation, as well as software packages and related files.

Both modes may involve various aspects of security, key distribution,and forward error correction techniques, for example. In some cases, anMBMS transaction may involve using a non-MBMS channel (e.g., a unicastchannel) for some aspects of the transaction, such as requestingparticular content, acknowledging such a request, and/or verifyingdelivery of a download. For the purposes described herein, any sort ofsignaling mechanism, in-band or out-of-band, may be used for thesepurposes. For instance, the Real Time Streaming Protocol (RSTP), theSession Description Protocol (SDP), and the File Delivery overUnidirectional Transport (FLUTE) protocol may be used alone or incombination to facilitate MBMS transactions.

As noted above, MBMS may be used for transmission of both multimediacontent and non-multimedia content. As such, it is expected that themultimedia content may require significantly more MBMS channel capacitythan the non-multimedia content. For example, streaming ahigh-definition, two or three hour long movie to wireless computingdevices may require as much as 25 gigabytes of MBMS channel capacity. Incontrast, an operating system update may require less than 1 gigabyte ofMBMS channel capacity, and application updates may require only a fewtens of megabytes of MBMS channel capacity.

Given these factors, it may be desirable to schedule downloads inbetween multimedia transmissions, or when the multimedia transmissionsare not using the entire capacity of the MBMS channel. As one example,MBMS channels may be used to stream live football games to wirelesscomputing devices. But, since football games, as well as other sportingevents, typically take place during the day or the evening, the MBMSchannels may have unused capacity overnight. Thus, downloads can bescheduled for WCDs during these overnight hours.

This overnight scheduling may be convenient for users who typically donot use their wireless computing devices during overnight hours. Whenthese users check their devices in the morning, they may be pleased tofind that one or more updates have been downloaded and are ready forinstalling, or have been automatically installed.

As another example, many video transmissions are variable-bit-rate. Theamount of capacity that the video transmission uses at any particularpoint in time may be based on the complexity of the scene. A scene witha significant amount of movement or action may require a higher bitrate(more capacity) than a relatively static scene. Therefore, somedownloads may be scheduled to occur on the same MBMS channel as avariable-bit-rate video transmission, when the video transmission isusing less than a threshold amount of the MBMS channel's capacity.

An additional advantage to scheduling downloads via an MBMS channel isthat wireless computing devices may use less power to receive thesedownloads from the MBMS channel than a unicast channel. Since MBMSchannels are unidirectional downlink channels, wireless computingdevices only receive on these channels. Receiving typically uses lesspower than transmitting. As a result, receiving downloads via an MBMSchannel may use less power, and therefore less battery capacity, thanunicast transmissions where the wireless computing device isperiodically transmitting acknowledgements to a unicast sender.

A further advantage to scheduling downloads via an MBMS channel is thatit allows wireless service providers and application providers to pushimportant and critical software updates to wireless computing devices ina rapid fashion. For example, normal-priority software updates may bescheduled for distribution to wireless computing devices over the courseof a one or two week period, in order to spread out the load on serverssupporting these downloads. Even if wireless computing devices areconfigured to check the availability of new software updates every fewhours or once a day, these software updates may not be visible to aparticular wireless computing device until that device's scheduleddownload time.

But when MBMS is used, one transmission from a download server canpotentially reach thousands, or even hundreds of thousands, of wirelesscomputing devices. Thus, these devices can all be informed of ascheduled time for the download, and may receive the download at thattime. Therefore, a large percentage (e.g., 90% or more) of these WCDsmay be able to receive and install a critical software update in lessthan 24 hours.

The embodiments herein provide implementations of scheduling andproviding MBMS-based software package transmissions to wirelesscomputing devices. The next section describes illustrative examples ofsuch computing devices and systems.

2. Example Communication System

FIG. 1 illustrates an example communication system 100 for carrying outone or more of the embodiments described herein. Communication system100 may include computing devices for carrying out one or moreoperations or procedures. Herein, a “computing device” may refer toeither a client device (e.g., a wireless computing device), a serverdevice (e.g., a networked cluster of server equipment), or some othertype of computational platform.

Wireless computing devices 102, 104, 106, 108 may be any type of devicecapable of wireless communication, including laptop computers, wearablecomputing devices, head-mountable computing devices, mobile telephones,radios, televisions, or tablet computing devices, etc. In FIG. 1,wireless computing devices 102, 104, 106, 108 may communicate withcontent server device 120 via wireless service provider radio accessnetwork 110 and IP network 118, or via wireless service provider radioaccess network 114 and IP network 118.

Each of wireless computing devices 102, 104, 106, 108 may include a userinterface, a communication interface, a processor, and data storage(e.g., memory). The data storage may contain instructions executable bythe processor for carrying out one or more operations relating to thedata sent to, or received from, content server device 120. The userinterface of wireless computing devices 102, 104, 106, 108 may includebuttons, a touchscreen, a microphone, and/or any other elements forreceiving inputs, as well as a speaker, one or more displays, and/or anyother elements for communicating outputs. Wireless computing devices102, 104, 106, 108 may contain MBMS components 102A, 104A, 106A, and108A, respectively. Each of these MBMS components may be a software orhardware module configured to receive media and/or download content fromcontent server device 120, and/or other MBMS enabled content serverdevices, as well as to communicate in other ways with content serverdevices.

Wireless service provider radio access networks 110, 114 may operate inaccordance with Code Division Multiple Access (CDMA), WorldwideInteroperability for Microwave Access (WIMAX®), Universal MobileTelecommunications System (UMTS), LTE®, or any other wide-area orcellular communication technology. In some cases, these radio accessnetworks may operate in accordance with a local-area communicationtechnology, such as Wifi. As such, wireless service provider radioaccess networks 110, 114 may include one or more base stations, basestation controllers, data access nodes, voice switches, signaling nodes,and user profile databases to support communication with wirelesscomputing devices.

Wireless service provider radio access networks 110, 114 also define oneor more MBMS channels, such as MBMS channel 112 and MBMS channel 116,respectively. Each MBMS channel may support multicasting and/orbroadcasting one or more simultaneous transmissions via a radio accessnetwork to wireless computing devices. Although each MBMS channel isshown transmitting to two wireless computing devices, anywhere from oneto thousands of wireless computing devices may receive each transmissionsent on an MBMS channel.

Each of wireless service provider radio access networks 110, 114 mayconnect to IP network 118. IP network 118, in turn, may be a private IPnetwork or the Internet. Via IP network 118, communications may beexchanged between wireless service provider radio access networks 110,114 and content server device 120.

Content server device 120 may be any entity or computing device arrangedto carry out the operations described herein. Further, content serverdevice 120 may be configured to send and/or receive data from wirelesscomputing devices 102, 104, 106, 108. Content server device 120 mayinclude an MBMS component 122, which may be configured to schedule MBMStransmissions, process MBMS requests received from wireless computingdevices 102, 104, 106, 108, and carry out MBMS transmissions to thesewireless computing devices. MBMS component 122 may be software and/orhardware configured for these purposes. Further, content server device120 may be configured to provide an MBMS transmission to wirelesscomputing devices 102, 104 via wireless service provider radio accessnetwork 110, and to wireless computing devices 106, 108 via wirelessservice provider radio access network 114.

In some cases, content server device 120 may include or have access to adatabase of content (not shown), such as audio content, audio/videocontent, and/or software packages that can be transmitted via MBMSprocedures. Other content and/or data may also be stored or accessibleby this database.

FIG. 1 is merely an illustrative embodiment. As such, other types ofdevices not shown may be present, and more or fewer of any devices maybe deployed in various configurations. For instance, more than fourwireless computing devices may receive MBMS transmissions, and more thanone content server may provide MBMS transmissions via any number ofwireless service provider radio access networks. Further, these contentserver devices may reside within a wireless service provider radioaccess network, and may be partially or wholly controlled by thewireless service provider.

FIG. 2 illustrates a schematic drawing of an example wireless computingdevice 200, where wireless computing device 200 is an example embodimentof one of wireless computing devices 102, 104, 106, 108. Thus, wirelesscomputing device 200 may, for example, take the form of any wirelesscomputing devices described above in relation to FIG. 1. In someexamples, components illustrated in FIG. 2 may be distributed acrossmultiple wireless computing devices. Nonetheless, for illustrativepurposes, components are shown and described in FIG. 2 as part of anexample wireless computing device 200.

In some implementations, wireless computing device 200 may include adevice platform or operating system (not shown). The device platform mayinclude different applications and an application framework, as well asvarious kernels, schedulers, memory managers, libraries, and runtimeentities. In other examples, other modules or sub-systems may operate onwireless computing device 200 as well.

Wireless computing device 200 may include an interface 202, an MBMScomponent 204, a communication component 206, data storage 208, and aprocessor 210. Components illustrated in FIG. 2 may be linked togetherby a communication bus 212. Wireless computing device 200 may alsoinclude additional hardware to enable further functionality and/oroperations.

Interface 202 may be configured to allow a user to interact withwireless computing device 200. Thus, interface 202 may includeuser-interface components, such as a keyboard, microphone, touchscreen,touchpad, display, speaker, etc.

MBMS component 204 may be software and or hardware configured to carryout any MBMS operations described herein. Thus, for instance, MBMScomponent 204 may be able to request particular media or downloadcontent from a content server device, receive an indication of the MBMSchannel that will provide this content, instruct communication component206 to tune to this channel, and then receive and process this MBMScontent. Other examples are also possible.

Communication component 206 may be a communication interface that isconfigured to facilitate wireless data and/or voice communicationaccording to one or more wide-area wireless communication standards ornon-standard protocols. For example, communication component 206 may beconfigured to facilitate wireless data communication according to CDMA,WIMAX, UMTS, LTE, or other protocols now known or later developed.Local-area wireless communication standards, such as Wifi, may besupported as well.

Data storage 208 may store program logic 214 that can be accessed andexecuted by processor 210. Program logic 214 may includemachine-readable instructions that, when executed by processor 210,cause wireless computing device 200 to carry out various operations andprocedures. To the extent that MBMS component 204 is software, thissoftware may be part of program logic 214.

Data storage 208 may also store data 216 that may include data receivedvia MBMS procedures, such as media and/or download data. Data storage208 may store additional data as well. Data storage 208 may be anon-transitory computer-readable data medium, such as a hardware memorymodule.

Processor 210 may be any type of one or more microprocessors orgeneral-purpose processors. However, processor 210 may be integratedwith or include various types of co-processors, network processors,graphics processors, and/or digital logic.

Communication bus 212 is illustrated as a wired connection; however,wireless connections may also be used. For example, communication bus212 may be a wired serial bus such as a universal serial bus or aparallel bus, or a wireless connection using, e.g., short-range wirelessradio technology, communication protocols described in IEEE 802.11(including any IEEE 802.11 revisions), or cellular technology, amongother possibilities.

FIG. 3 illustrates a schematic drawing of another example computingdevice, content server device 300. In examples, some componentsillustrated in FIG. 3 may be distributed across multiple physicalcontent server devices. However, for the sake of illustration andsimplicity, the components are shown and described as part of oneexample content server device 300. Content server device 300 may be acomputing device, cloud-based server, or similar entity that may beconfigured to perform the operations described herein. For instance,content server device 300 may be an embodiment of content server device120.

Content server device 300 may include a communication interface 302, anMBMS component 304, a processor 306, and data storage 308. All of theelements illustrated in FIG. 3 may be linked together by a communicationbus 310 (e.g., a wired or wireless link).

Communication interface 302 may allow content server device 300 tocommunicate with other devices, such as wireless computing devicesdescribed above in relation to FIG. 2. Thus, communication interface 302may be configured to receive input data from one or more computingdevices, and may also be configured to send output data to the one ormore computing devices (e.g., wireless computing devices or other typesof devices).

MBMS component 304 may be software and or hardware configured to carryout any MBMS operations described herein. Thus, for instance, MBMScomponent 304 may be able to receive requests for particular media ordownload content from wireless computing devices, transmit an indicationof the MBMS channel over which this content will be transmitted, andthen transmit this MBMS content over the indicated MBMS channel. In somecases, the MBMS content may be retrieved from content database 314 priorto transmission. Other examples are also possible.

Data storage 308 may store program logic 312 that can be accessed andexecuted by processor 306. To the extent that MBMS component 304 issoftware, this software may be part of program logic 312.

Data storage 308 may also include content database 314 that can beaccessed by processor 306 as well, for example, to retrieve media and/ordownload content. The content in content database 314 may include storedaudio content, stored audio/video content, references to live audiocontent feeds (e.g., live radio), references to live audio/video contentfeeds (e.g., live television), and/or software packages. The referencesmay be uniform resource locators, or other types of identifiers, of thelive feeds. These live feeds may stream through content server device300.

Like data storage 212, data storage 308 may be a non-transitorycomputer-readable data medium, such as a hardware memory module. Also,like processor 210, processor 306 may be any type of one or moremicroprocessors or general-purpose processors, and may be integratedwith or include various types of co-processors, network processors,graphics processors, and/or digital logic.

3. Example MBMS Scheduling

FIG. 4 is a depiction of transmission schedules, according to exampleembodiments. In FIG. 4, partial schedules are shown for two MBMSchannels, MBMS channel M and MBMS channel N. In an actual MBMS system,however, more or fewer MBMS channels may be used.

For MBMS channel M, two media transmissions are scheduled. Mediatransmission 400 ends at time 420, and media transmission 406 begins attime 430. In between time 420 and time 430, MBMS channel M mightinitially be idle. Consequently, software package transmission 402 isscheduled to begin at time 422 and end at time 424, and software packagetransmission 404 is scheduled to begin at time 426 and end at time 428.These software package transmissions may have been scheduled for timeswhen MBMS channel M is idle so that the software package transmissionsdo not interfere with the media transmissions. Idle time periods of MBMSchannel M are represented by cross-hatching.

For MBMS channel N, one media transmission is scheduled. Mediatransmission 408 begins before the time period illustrated in FIG. 4,and ends after this time period. However, from time 440 to time 442, andfrom time 444 to time 446, there may be spare capacity on MBMS channelN. As an example, these time periods (from time 440 to time 442, andfrom time 444 to time 446) may represent epochs in which the mediatransmission may use less than a threshold amount of the capacity ofMBMS channel N. This threshold amount may be 10%, 20%, 50%, or someother relative or absolute measure of channel capacity. Any sparecapacity of MBMS channel N is not shown in FIG. 4.

Consequently, software package transmission 410 may be scheduled tobegin transmission at time 440, and end transmission at time 442.Software package transmission 412 may be scheduled to begin transmissionat time 444, and end transmission at time 446.

The size of each software package (e.g., as measured in kilobytes,megabytes, or gigabytes—the sizes may vary based on the complexity ofthe software package and the extent of forward error correction used inthe MBMS transmission of the software package) and the data rate and/orspare capacity of each MBMS channel may be taken into account whenscheduling software package transmissions. For instance, based on thedata rate and spare capacity of an MBMS channel, a particular softwarepackage may be scheduled for transmission during a time period in whichit can be completely transmitted without exceeding the capacity limitsof the MBMS channel.

FIG. 5 is a message flow diagram depicting an example MBMS transactionbetween wireless computing device 500 and content server device 502.Wireless computing device 500 may be any type of device configured toreceive MBMS transmissions, such as example wireless computing device200. Content server device 502 may be any device configured to provideMBMS transmissions, such as example content server device 300.

In FIG. 5, communication on a unicast (point-to-point) channel isdepicted with a thin line (see steps 506 and 508) and communication onan MBMS channel is depicted with a thicker line (see step 512).

At step 504, content server device 502 may schedule media and softwarepackage transmissions on one or more MBMS channels. Alternatively,content server device 502 may schedule media and software packagetransmissions, and other devices (such as radio access network devices)may determine which MBMS channels these transmissions will use.

At step 506, wireless computing device 500 may transmit a softwareupdate request to content server device 504. Wireless computing device500 may transmit this request as part of a device information exchangeto an Open Mobile Alliance (OMA) device management (DM) server, aFirmware Update Management Object (FUMO) server, or a firmwareover-the-air (FOTA) server.

This software update request may seek to determine whether there are anysoftware packages used by wireless computing device 500 that should beupdated. These software packages may include operating system packages,library packages, application packages, and/or data files.Alternatively, the software update request may seek to determine whethera particular software package should be updated.

As an example, an application developer may release new versions of aparticular application to one or more application stores. Theseapplication stores may be portals through which applications can bepurchased and/or downloaded. In order to be able to download these newversions in a timely fashion, a wireless computing device mayperiodically, or from time to time, query the application store. Theapplication store may, in turn, notify the wireless computing device ofwhich (if any) software packages have been updated. Then, the wirelesscomputing device can download the updated software package(s).

Content server device 502 may take on some or all operations of such anapplication store, and may incorporate MBMS operations as well. Forinstance, rather than having the application store transmit, viaunicast, hundreds or thousands of copies of an updated software packageto wireless computing devices individually, content server device 502may schedule a limited number of MBMS transmissions of the softwarepackage, and inform wireless computing devices of these MBMStransmissions. The wireless computing devices may then have an option toeither (i) immediately download the software update via unicast, or (ii)wait for one of the scheduled MBMS transmissions.

The user of a wireless computing device may be incentivized to wait forthe MBMS transmission. For instance, the wireless service provider towhich the user subscribes might not charge for receiving MBMStransmissions, and/or might not count such receptions toward the user'sdata usage. Further, as noted above, the user might be informed thatreceiving MBMS transmissions may use less power than unicasttransmissions. Therefore, if the user is concerned about conserving hisor her battery life, the user might be motivated to wait for an MBMStransmission.

Regardless, at step 508, content server device 502 may transmit an MBMSchannel identifier and an indication of a time at which the softwarepackage transmission is scheduled. The identifier may include the IPaddress of an MBMS server (e.g., content server device 502) and atransport session identifier (TSI) of the software package transmission.The TSI may be a bit string or code that uniquely identifies thetransmission, per IP address. For instance, each IP address/TSI pair mayuniquely identify an MBMS transmission before, during, and/or after thetime that transmission is active.

Alternatively or additionally, the identifier may include one or moretransport object identifiers (TOIs). A TOI may be used to uniquelyidentify an object (e.g., a file or a message) within an MBMStransmission. Thus, a specific object can be uniquely identified by thecombination of MBMS server IP address, TSI, and TOI. In someembodiments, an OMA DM server can include the TSI and/or the TOI alongwith a uniform resource locator (URL) in the download node of an OMAmanagement object. Optionally, the identifier may indicate to thewireless computing device what radio technology to use when receivingthe particular software package. Such a radio technology may includeMBMS (broadcast), LTE®, Wifi, and other types of local-area or wide-arearadio technologies.

In some cases, the MBMS channel identifier may also identify thefrequency of the identified MBMS channel. To that point, at step 510,wireless computing device 500 may tune to the identified MBMS channel,so that wireless computing device 500 can receive MBMS transmissions onthis channel. Wireless computing device 500 may perform this tuningprocedure prior to the time at which the software package transmissionis scheduled.

It is possible that content server device 502 performs step 508 withoutbeing triggered to do so by wireless computing device 500. For instance,content server device 502 may be aware of the software packagesinstalled on wireless computing device 500, and may transmit anindication to wireless computing device 500 when one or more of thesesoftware packages have been updated and/or are scheduled for MBMSdownload. This indication can be triggered by a Push Initiation message,which may be sent from an OMA DM server.

At step 512, which takes place at this time, content server device 502may transmit the software package on the identified MBMS channel. Thistransmission may be one of potentially many made by content serverdevice 502 and/or other devices, on the identified MBMS channel and/orother MBMS channels.

In some embodiments, transmission of the software package to thewireless computing device may occur from an OMA DM server.Alternatively, some of the MBMS transaction may occur between thewireless computing device and an OMA DM server, while the transmissionof the software package may be performed by a separate content serverdevice.

The separate content server device can make use of MBMS to transmit thesoftware package to the wireless computing device. When the OMA DMserver device determines that it is to carry out a software update withthe wireless computing device, it can communicate this intent to thecontent server device by indicating the urgency, the size, and thepackage that is to be transmitted. The content server device candetermine when the package can be transmitted using MBMS, and respondwith the associated transmission schedule to the OMA DM server device.If the content server device has no MBMS resources to meet therequirements indicated by the OMA DM server device, the content serverdevice can respond with a negative acknowledgment to the OMA DM serverdevice. This may allow the OMA DM server device to find an alternativedownload mechanism.

FIG. 5B is a flow chart that illustrates these embodiments. At step 522,OMA DM server device 520 may transmit a push initiation message towireless computing device 500. An OMA DM server may be arranged todeliver configuration parameters to an OMA DM client, such as wirelesscomputing device 500, by using a set of commands for various managementprocedures. These commands may be executed by the OMA DM client. The OMADM client, in turn, exposes some of its internal data to the OMA DMserver in the form of a hierarchy known as a DM tree. Regardless, thepush initiation message may open communication between wirelesscomputing device 500 and OMA DM server device 520. In some cases, thepush initiation may be transmitted by wireless computing device 500.

At step 524, device information exchange may occur. In this step,wireless computing device 500 may provide at least a minimum set ofselection criteria so that OMA DM server device 520 can determine anappropriate software package for wireless computing device 500.

At step 526, OMA DM server device 520 may transmit a replace command towireless computing device 500. The argument of this command,FwPkg1/Download/PkgURL, indicates which software package is to bereplaced. Thus, the example in FIG. 5B is merely for purposes ofillustration, and different arguments can take on different values basedon the software package being replaced. In some embodiments, thiscommand may contain the transmission schedule, TOI, TSI and/or URL ofthe software package.

At step 528, OMA DM server device 520 may transmit an exec command towireless computing device 500. This command instructs wireless computingdevice 500 to download the new version of the software package fromcontent server device 502. (In some embodiments, a user may be promptedto approve this download before the download takes place.) Additionally,this command may contain the transmission schedule, TOI, TSI and/or URLof the package. Upon reception of the exec command, wireless computingdevice 500 can use the transmission schedule to determine when to wakeup in order to receive the software package. Optionally, the execcommand may indicate to the wireless computing device what radiotechnology to use when receiving the particular software package. Such aradio technology may include MBMS (broadcast), LTE®, Wifi, and othertypes of local-area or wide-area radio technologies.

Step 530, shown with a dashed line, illustrates an alternativeembodiment. Wireless computing device 500 may request the softwarepackage from content server device 502, and content server device 502may transmit the requested software package to wireless computing device500. Wireless computing device 500 may then perform the installation ofthe software package, again with optional approval from the user.

Upon determining that the software package will be transmitted using thetransmission schedule, wireless computing device 500 may ignore step530. Instead, wireless computing device 500 may wake up at step 531 toreceive the software package transmitted by the content server deviceusing MBMS at step 532. During reception, wireless computing device 500can check if the parameters package transmitted at the transmissionschedule time match the TOI, TSI and/or URL indicated by the OMA DMserver device.

Regardless of how wireless computing device 500 obtains the softwarepackage, at step 534, wireless computing device 500 may transmit adownload notification to OMA DM server device 520. The downloadnotification may serve to inform OMA DM server device 520 of whether thesoftware update download and/or installation succeeded.

At step 536, OMA DM server device 520 may transmit another exec commandto wireless computing device 500. This exec command may instructwireless computing device 500 to update its DM tree. In particular, theexec command may instruct wireless computing device 500 to execute anupdate of the existing version of the software package with thedownloaded version. (In some embodiments, a user may be prompted toapprove this replacement before it the replacement takes place.) Then,at step 538, the MBMS transaction completes when wireless computingdevice 500 transmits a final notification to OMA DM server device 520.

4. Example Operations

FIG. 6 is a flow chart illustrating an example embodiment. The procedureillustrated by FIG. 6 may be carried out by a computing device, such ascontent server device 300, or by some combination of devices. However,the procedure can be carried out by other types of devices or devicesubsystems. For instance, the computing device that schedules MBMStransmissions may be different from the content server device thatcarries out these transmissions. Further, the procedure may furtherincorporate any other aspect or feature disclosed herein.

At block 600, a computing device may schedule transmission of softwarepackages on a broadcast/multicast downlink channel (e.g., an MBMSchannel). The broadcast/multicast downlink channel may be a cellularchannel. The schedule may also include media transmissions on thebroadcast/multicast downlink channel. The software package transmissionsmay be scheduled for times when the media transmissions are using lessthan or equal to a threshold capacity level of the broadcast/multicastdownlink channel.

At block 602, a software update request or device information exchangemessage may be received from a wireless computing device. At block 604,possibly in response to receiving the software update request or deviceinformation exchange message, a particular software package related tothe wireless computing device may be determined. The particular softwarepackage may have been scheduled to begin transmission on thebroadcast/multicast downlink channel at a particular time. At block 606,at least an identifier of the broadcast/multicast downlink channel, andthe particular time, may be transmitted to the wireless computingdevice. This identifier may include an IP address of a content serverdevice, and a TSI for the transmission of the particular softwarepackage. The identifier can also be a URL. In some embodiments, the URLcould contain transmission time information and other identifiersincluding an indication that download using MBMS is preferred for thesoftware package.

In some implementations, the particular software package, and itsassociated TSI and/or TOI, may be transmitted on the broadcast/multicastdownlink channel at the particular time. After such a transmission, itmay be determined that the transmission of the particular softwarepackage was not properly received by the wireless computing device.Possibly in response, an instruction may be transmitted to the wirelesscomputing device to download the particular software package via anetwork mechanism other than the broadcast/multicast downlink channel.For instance, a Wifi or cellular unicast channel may be used as a backupin case an MBMS transmission is not properly received by the wirelesscomputing device. The network may indicate to the wireless computingdevice what radio technology to use when receiving the particularsoftware package. Such a radio technology may include MBMS, LTE®, Wifi,and other types of local-area or wide-area radio technologies.

In some cases, transmission of high-priority software packages may bescheduled before transmission of low-priority software packages on thebroadcast/multicast downlink channel. Thus, for instance, transmissionof critical software updates may take priority over transmission ofnon-critical software updates. A critical software update may be pushedto wireless computing devices in order to fix a security flaw, stabilityproblem, or improper functionality of a previously-distributed versionof the software package.

As noted above, software package transmissions may be scheduled fortimes when the media transmissions are using less than or equal to athreshold capacity level of the broadcast/multicast downlink channel. Insome cases, this threshold capacity level is zero, indicating that thesoftware package transmissions only occur when the broadcast/multicastdownlink channel is not being used for media transmission. On the otherhand, when the threshold capacity level is non-zero, the one or moresoftware packages are scheduled for transmission while the particularmedia transmission is taking place.

In some situations, one or more of the software packages may be relatedto content of a particular media transmission. For instance, if themedia transmission is a football game, the software package may be anapplication related to one or more of the football league that is aputting on the game, the teams involved in the game, the playersinvolved in the game, and so on. Data to be used with such anapplication, including advertisements targeted to football fans or toparticular markets located near the wireless computing device, may alsobe transmitted to wireless computing devices in this fashion.

Similarly, if the media transmission is an episode of a televisionseries or a movie, the software package may be an application related tothe television series or movie. For instance, the software package mayallow users to answer live poll questions, obtain additional informationabout the television series or movie, and/or play games related to thetelevision series or movie.

Nonetheless, the software packages transmitted during a mediatransmission need not be related to the media transmission. Forinstance, various software package transmissions may be scheduled fortimes when the media transmission is not using the entire extent of itsassigned broadcast/multicast downlink channel.

In some embodiments, the schedule may be transmitted to the wirelesscomputing device as part of a device management update, or by using theupdate or download node of an OMA DM command. In some cases, theschedule can be part of a PkgURL node transmission to the wirelesscomputing device. Regardless, such a device management update may be amechanism by which a wireless service provider informs wirelesscomputing device users that there are one or more software packages ordata file updates available for their wireless computing devices.Signaling or data channels of the wireless service provider's radioaccess network may be used to provide these device management updates.

In some situations, wireless computing devices may use less power toreceive software packages over the broadcast/multicast downlink channelthan other types of wireless channels. Thus, the particular softwarepackage may be scheduled to be transmitted on the broadcast/multicastdownlink channel to reduce power consumption by the wireless computingdevice.

5. Conclusion

The present disclosure is not to be limited in terms of the particularembodiments described in this application, which are intended asillustrations of various aspects. Many modifications and variations canbe made without departing from its scope, as will be apparent to thoseskilled in the art. Functionally equivalent methods and apparatuseswithin the scope of the disclosure, in addition to those enumeratedherein, will be apparent to those skilled in the art from the foregoingdescriptions. Such modifications and variations are intended to fallwithin the scope of the appended claims.

The above detailed description describes various features and functionsof the disclosed systems, devices, and methods with reference to theaccompanying figures. The example embodiments described herein and inthe figures are not meant to be limiting. Other embodiments can beutilized, and other changes can be made, without departing from thescope of the subject matter presented herein. It will be readilyunderstood that the aspects of the present disclosure, as generallydescribed herein, and illustrated in the figures, can be arranged,substituted, combined, separated, and designed in a wide variety ofdifferent configurations, all of which are explicitly contemplatedherein.

With respect to any or all of the message flow diagrams, scenarios, andflow charts in the figures and as discussed herein, each step, block,and/or communication can represent a processing of information and/or atransmission of information in accordance with example embodiments.Alternative embodiments are included within the scope of these exampleembodiments. In these alternative embodiments, for example, functionsdescribed as steps, blocks, transmissions, communications, requests,responses, and/or messages can be executed out of order from that shownor discussed, including substantially concurrent or in reverse order,depending on the functionality involved. Further, more or fewer blocksand/or functions can be used with any of the ladder diagrams, scenarios,and flow charts discussed herein, and these ladder diagrams, scenarios,and flow charts can be combined with one another, in part or in whole.

A step or block that represents a processing of information cancorrespond to circuitry that can be configured to perform the specificlogical functions of a herein-described method or technique.Alternatively or additionally, a step or block that represents aprocessing of information can correspond to a module, a segment, or aportion of program code (including related data). The program code caninclude one or more instructions executable by a processor forimplementing specific logical functions or actions in the method ortechnique. The program code and/or related data can be stored on anytype of computer readable medium such as a storage device including adisk, hard drive, or other storage medium.

The computer readable medium can also include non-transitory computerreadable media such as computer-readable media that store data for shortperiods of time like register memory, processor cache, and random accessmemory (RAM). The computer readable media can also includenon-transitory computer readable media that store program code and/ordata for longer periods of time. Thus, the computer readable media mayinclude secondary or persistent long term storage, like read only memory(ROM), optical or magnetic disks, compact-disc read only memory(CD-ROM), for example. The computer readable media can also be any othervolatile or non-volatile storage systems. A computer readable medium canbe considered a computer readable storage medium, for example, or atangible storage device.

Moreover, a step or block that represents one or more informationtransmissions can correspond to information transmissions betweensoftware and/or hardware modules in the same physical device. However,other information transmissions can be between software modules and/orhardware modules in different physical devices.

The particular arrangements shown in the figures should not be viewed aslimiting. It should be understood that other embodiments can includemore or less of each element shown in a given figure. Further, some ofthe illustrated elements can be combined or omitted. Yet further, anexample embodiment can include elements that are not illustrated in thefigures.

While various aspects and embodiments have been disclosed herein, otheraspects and embodiments will be apparent to those skilled in the art.The various aspects and embodiments disclosed herein are for purposes ofillustration and are not intended to be limiting, with the true scopebeing indicated by the following claims.

What is claimed is:
 1. A method, comprising: sending, from a computingdevice, a software update request for a particular software package; andafter sending the software update request, the computing devicereceiving at least an identifier of a broadcast/multicast downlinkchannel, and an indication of a particular time period of a plurality oftime periods in which the particular software package can be completelytransmitted without exceeding the capacity of the broadcast/multicastdownlink channel.
 2. The method of claim 1, further comprising: afterreceiving the identifier of the broadcast/multicast downlink channel andthe indication of the particular time period, the computing devicereceiving the particular software package during the particular timeperiod.
 3. The method of claim 2, wherein receiving the particularsoftware package during the particular time period comprises receivingthe particular software package and a transport object identifier of theparticular software package on the broadcast/multicast downlink channelduring the particular time period.
 4. The method of claim 1, furthercomprising: determining that the particular software package was notproperly received by the computing device; and receiving, at thecomputing device, an instruction to download the particular softwarepackage via a network mechanism other than the broadcast/multicastdownlink channel.
 5. The method of claim 1, wherein transmission of theparticular software package is scheduled for one or more times when oneor more media transmissions are using less than or equal to a thresholdcapacity level of the broadcast I multicast downlink channel.
 6. Themethod of claim 5, wherein the threshold capacity level of thebroadcast/multicast downlink channel is zero.
 7. The method of claim 5,wherein the threshold capacity level of the broadcast/multicast downlinkchannel is non-zero, wherein the particular software package is relatedto content of a particular media transmission, and wherein theparticular software package is scheduled for transmission during theparticular media transmission.
 8. The method of claim 1, wherein thecomputing device uses less power to receive software packages over thebroadcast/multicast downlink channel than other types of wirelesschannels, and wherein the particular software package is scheduled to betransmitted on the broadcast/multicast downlink channel to reduce powerconsumption by the computing device.
 9. The method of claim 1, whereinthe identifier of the broadcast/multicast downlink channel comprises anInternet Protocol (IP) address of a content server device, and atransport session identifier for transmission of the particular softwarepackage.
 10. A computing device, comprising: at least one processor;memory; and program instructions, stored in the memory, that uponexecution by the at least one processor cause the computing device toperform operations comprising: sending a software update request for aparticular software package; and after sending the software updaterequest, receiving at least an identifier of a broadcast/multicastdownlink channel, and an indication of a particular time period of aplurality of time periods in which the particular software package canbe completely transmitted without exceeding the capacity of thebroadcast/multicast downlink channel.
 11. The computing device of claim10, wherein the operations further comprise: after receiving theidentifier of the broadcast/multicast downlink channel and theindication of the particular time period, receiving the particularsoftware package during the particular time period.
 12. The computingdevice of claim 10, wherein receiving the particular software packageduring the particular time period comprises receiving the particularsoftware package and a transport object identifier of the particularsoftware package on the broadcast/multicast downlink channel during theparticular time period.
 13. The computing device of claim 10, whereinthe operations further comprise: determining that the particularsoftware package was not properly received by the computing device; andreceiving an instruction to download the particular software package viaa network mechanism other than the broadcast/multicast downlink channel.14. The computing device of claim 10, wherein transmission of theparticular software package is scheduled for one or more times when oneor more media transmissions are using less than or equal to a thresholdcapacity level of the broadcast I multicast downlink channel.
 15. Thecomputing device of claim 14, wherein the threshold capacity level ofthe broadcast/multicast downlink channel is zero.
 16. The computingdevice of claim 14, wherein the threshold capacity level of thebroadcast/multicast downlink channel is non-zero, wherein the particularsoftware package is related to content of a particular mediatransmission, and wherein the particular software package is scheduledfor transmission during the particular media transmission.
 17. Thecomputing device of claim 10, wherein the computing device uses lesspower to receive software packages over the broadcast/multicast downlinkchannel than other types of wireless channels, and wherein theparticular software package is scheduled to be transmitted on thebroadcast/multicast downlink channel to reduce power consumption by thecomputing device.
 18. The computing device of claim 10, wherein theidentifier of the broadcast/multicast downlink channel comprises anInternet Protocol (IP) address of a content server device, and atransport session identifier for transmission of the particular softwarepackage.
 19. An article of manufacture including a non-transitorycomputer-readable medium, having stored thereon program instructionsthat, upon execution by a computing device, cause the computing deviceto perform operations comprising: sending a software update request fora particular software package; and after sending the software updaterequest, receiving at least an identifier of a broadcast/multicastdownlink channel, and an indication of a particular time period of aplurality of time periods in which the particular software package canbe completely transmitted without exceeding the capacity of thebroadcast/multicast downlink channel
 20. The article of manufacture ofclaim 19, wherein the operations further comprise: after receiving theidentifier of the broadcast/multicast downlink channel and theindication of the particular time period, receiving the particularsoftware package during the particular time period.